Pré-requisitos: Documentação de Contexto
Definição do problema e ideia de solução a partir da perspectiva do usuário.
| Tipo de Usuário | Descrição | Responsabilidades |
|---|---|---|
| xxx | xxxxx | xxxxx |
| Tipo de Usuário | Descrição | Responsabilidades |
|---|---|---|
| Administrador | Gerencia a aplicação e os usuários. | Gerenciar usuários, configurar o sistema, acessar todos os relatórios. |
| Funcionário | Usa a aplicação para suas tarefas principais. | Criar e editar registros, visualizar relatórios. |
Descreva brevemente a arquitetura definida para o projeto e as tecnologias a serem utilizadas. Sugere-se a criação de um diagrama de componentes da solução.
Deve ser desenvolvido a partir do microfundamento: Empreendedorismo e inovação. Colocar a imagem do modelo construído apresentando a proposta de solução.
Links Úteis: Disponíveis em material de apoio do projeto
As tabelas que se seguem apresentam os requisitos funcionais e não funcionais que detalham o escopo do projeto. Para determinar a prioridade de requisitos, aplicar uma técnica de priorização de requisitos e detalhar como a técnica foi aplicada.
Para mais informações, consulte os microfundamentos Fundamentos de Engenharia de Software e Engenharia de Requisitos de Software.
| ID | Descrição do Requisito | Prioridade |
|---|---|---|
| RF-001 | Permitir que o usuário cadastre tarefas | ALTA |
| RF-002 | Emitir um relatório de tarefas no mês | MÉDIA |
| ID | Descrição do Requisito | Prioridade |
|---|---|---|
| RNF-001 | O sistema deve ser responsivo para rodar em um dispositivos móvel | MÉDIA |
| RNF-002 | Deve processar requisições do usuário em no máximo 3s | BAIXA |
Com base nas Histórias de Usuário, enumere os requisitos da sua solução. Classifique esses requisitos em dois grupos:
- Requisitos Funcionais (RF): correspondem a uma funcionalidade que deve estar presente na plataforma (ex: cadastro de usuário).
- Requisitos Não Funcionais (RNF): correspondem a uma característica técnica, seja de usabilidade, desempenho, confiabilidade, segurança ou outro (ex: suporte a dispositivos iOS e Android). Lembre-se que cada requisito deve corresponder à uma e somente uma característica alvo da sua solução. Além disso, certifique-se de que todos os aspectos capturados nas Histórias de Usuário foram cobertos.
O projeto está restrito pelos itens apresentados na tabela a seguir.
| ID | Restrição |
|---|---|
| 01 | O projeto deverá ser entregue até o final do semestre |
| 02 | Não pode ser desenvolvido um módulo de backend |
Enumere as restrições à sua solução. Lembre-se de que as restrições geralmente limitam a solução candidata.
Links Úteis:
O diagrama de casos de uso é o próximo passo após a elicitação de requisitos, que utiliza um modelo gráfico e uma tabela com as descrições sucintas dos casos de uso e dos atores. Ele contempla a fronteira do sistema e o detalhamento dos requisitos funcionais com a indicação dos atores, casos de uso e seus relacionamentos.
Para mais informações, consulte o microfundamento Engenharia de Requisitos de Software
As referências abaixo irão auxiliá-lo na geração do artefato “Diagrama de Casos de Uso”.
Links Úteis:
O projeto da base de dados corresponde à representação das entidades e relacionamentos identificadas no Modelo ER, no formato de tabelas, com colunas e chaves primárias/estrangeiras necessárias para representar corretamente as restrições de integridade.
Para mais informações, consulte o microfundamento "Modelagem de Dados".